Scrum

introducción

Es un Framework principalmente usada en el desarrollo de software que se puede implementar con muchas herramientas que "automatizan" el proceso como Github. Aunque puede ser usada en cualquier desarrollo de proyectos. Es un framework de trabajo en Equipo, lo que quiere decir que se pueden trabajar desde 4 personas en adelante, Por ejemplo: Visual Code, tiene un equipo de 1461 persona en julio de 2021, divididas en 281 proyectos -características- del editor en más de 100 paises alrededor del mundo, usando como "guia de desarrollo" el RoadMap que tiene propositos tan ambiguos como

Continue on our journey to be the best editor for anyone who relies on accessibility features lo cual solo dice su predisposición al cambio, que es una de las características que veremos mas adelante.

tabla de contenidos

definiciones

roles

Lo primero que se necesita es entender los roles. Todo el equipo desempeña una función y esta debe ser clara desde el inicio. Por tanto entender los roles es una de las características mas importantes del FrameWork.

como características (skills) del equipo se espera:

=> es ideal que el DevTeam sea entrevistado por el mismo DevTeam, no por alguien de recursos humanos.

Usuario(users):

es la persona que se impacta directamente con el uso de nuestra tecnología, Dispositivo, Software o Proyecto. Por Ejemplo: la persona que USA whatsApp, o la persona que USA facebook, etc. no hace parte del equipo pero esta en la visión global

customers(stakeholders, tomadores de decisiones):

son áreas o personas dentro de la organización que puede incidir en algún modo en el proyecto pero no directamente. Por ejemplo: contabilidad con recortes de presupuesto, mercadotécnica con métricas de compra de la aplicación, etc. Se comunican con el Producto Owner y no pertenecen directamente al equipo de Scrum, pero están en el panorama global.

Tomadores de decisiones(Cliente):

son las personas que buscan el desarrollo de un producto, característica, tecnología o proyecto. Ellos contactan con áreas como Ventas, Soporte (stakeholders) y en nuestro caso con el Product Owner. Ellos a su vez pueden tener sus clientes (Por ejemplo: nuestro cliente es UBER pero SUS clientes son las personas que toman el carro) que para nosotros serán los usuarios. No son parte del equipo Scrum

Product Owner(PO):

es el contacto principal entre el cliente y el grupo de desarrollo. A veces llamado cliente interno, sus funciones principales son "traducir" (tarea muy difícil como retratan con humor en este sketch) y ayuda a priorizar las tareas del cliente externo ayudándole a entender que se debe enfocar primero. Las características esperadas en la aplicación o tecnología (Backlog) o la revisión de las características ya estructuradas (review). Se espera como características de un PO(features) la comunicación, las métricas, el punto de vista de stakeholders y resuelve o consigue la información necesaria para el DevTeam( no tiene que tener toda la información pero si conseguir la información), además del conocimiento tanto de administración como de programación por lo que la carrera ideal es un ingeniero industrial, pero puede ser un psicólogo, o un administrador de empresas. No es necesario que sepa Scrum, es deseable pero no obligatorio. Si el producto falla es responsabilidad del PO, por ello debe priorizar claramente los objetivos a conseguir.

Scrum Master(scrum):

primera claridad no es el Jefe, no es un gestor, ni un líder. Es un facilitador que hace parte del equipo, que dirige las ceremonias de Scrum, y ayuda al uso de la metodología en el desarrollo. Estima el tiempo de cada tarea y vigila los tiempos, define los Sprint. Puede darse el caso que el Scrum Master sea también un Development, No debe darse el caso que un Scrum Master sea a su vez Product Owner.

DevTeam:

son los profesionales que se encargan de crear el producto, se definen principalmente por sus capacidades técnicas especializadas (backend, frontend, Datase Administration, Fullstack, devOps, el conocimiento de un lenguaje especifico). En el caso que el proyecto no sea de software pues serán los especialistas en cada rama. deben saber Scrum, pero no necesariamente ser expertos en el Frame. no hay un lider de ellos, el equipo es Autoorganizado y autogestionado y son quienes deciden que tecnologia se debe usar para cada una de los desarrollos. Como se asume que cada uno es experto en el area no necesita una guía sino que su cncepto es ley en su campo. Al tener que hacer una API o espacio de comunicación con otra area se deben llegar a concensos, esta tarea la facilita Git a través de sus conlifct developers y de sus request pull. Ellos deciden que tareas deciden hacer porque estan AUTOMOTIVADOS. Estas tareas en git se mueven desde los projects y sus columnas se definen en grupo pero se sugieren (toDo, Doing y Done). EN SCRUM NO HAY ROLES COMO TESTER, DEVELOPMENT, ETC. ESTO VIENE DEL WATERFALL.

scrum team: Product Owner + Scrum Master + DevTeam

erDiagram
  USER ||--|{ CUSTOMERS : "contacta a"
  CUSTOMERS ||--|{ PRODUCT_OWNER :  "asignan un"
  PRODUCT_OWNER ||--o{ SCRUMTEAM : "integra un"
  SCRUMTEAM }|..|{ SCRUMMASTER : "donde hay un"

valores

experiencia

se entiende como experiencia la toma de decisiones basada en decisiones iguales anteriores o en decisiones parecidas, esto procede del concepto matemático de regresión lineal y no es garantía que vaya a garantizar el éxito. Por ejemplo: Hoy Jueves llovió en la tarde, de manera similar que el Lunes Martes y Miércoles; lo que hace probable que mañana Viernes llueva. Pero no se garantiza que ocurra de ese modo.

Revision

Al pensar la metodología que el cambio es una constante y se debe preparar para ello, la revisión de los artefactos debe ser continua. Esto permite además de estar atento a cualquier cambio tener claro el objetivo a lograr. Una duda continua es qué tan frecuente debe ser continua, o cada cuánto tiempo es continua. la respuesta es depende:

  1. del mismo equipo de trabajo
  2. del proyecto y la variabilidad que tenga
  3. del ritmo de trabajo del equipo la regla general es tanto como se pueda, sin interferir con el desarrollo del objetivo.

Adaptación

Sabemos que las metodologías ágiles ven el cambio como una constante. Pues esa constante es la guiá el trabajo, pero para evitar cambios abruptos se establecen marcos de referencia para cambios. es decir, se detectan las variaciones y se miden dentro de limites de tolerancia permitidos. Sí están dentro el cambio no afecta el proyecto. si están fuera hay que modificar algo. Los tester deben estar continuamente monitoreando y haciendo pruebas sobre el producto desarrollado, de allí que tener el código centralizado como en Github permita no solo el trabajo en el desarrollo de características sino en el mismo test continuo.

Transparencia

el acceso a la información no debe ser en punto del desarrollo, sino que debe ser continuo, para todo interesado en el proyecto, en todo momento, en toda etapa. Todo lo que se desarrolle debe tener un responsable y un backup. para esto es necesario el desarrollo de patrones comunes altamente difundidos y comunicados con el equipo. Este es el punto central del uso de Git y de algún hub de código como github.

Git se convierte en la herramienta central del proceso Scrum al integrar el Scrum Board o tablero de actividades, la documentación o wiki, el código o source y gestionar tanto el acceso como las métricas y estadísticas del equipo. desplegar pruebas y generar tanto el backup como el front code constantemente por medio de las ramas o branch.

Por supuesto que no gestiona la transparencia de un equipo, pero si de su información, y esto facilita tener en cuenta esa comunicación con datos reales.

eventos

los eventos en sprint son las dinámicas que se llevan a cabo en cada periodo para:

Sprint

el Sprint es el proceso central que contiene otros procesos, en Github lo llaman Milestone. Puede durar mínimo una semana y un máximo de 4 Semanas, en las cuales se debe entregar un producto terminado, probado y documentado. Que debe funcionar independientemente de los Sprints futuros, pero puede funcionar como incremento de los Sprints pasados.

Cada Sprint tiene como objetivo una característica (feature) que desarrollar. Y en cada Sprint se desarrollan el resto de eventos que dan cuenta del avance del proyecto en general y de la característica en particular. Estos eventos se llaman ceremonias y son:

cada evento da cuenta de una planeación o evaluación del Sprint Goal (objetivo del Sprint).

un Sprint no es / no se hace:

en un sprint es / se hace:

se puede cancelar un Sprint???

en caso de fuerza mayor, el Product Owner y solo el Product Owner puede cancelar un Sprint. Se consideran casos de fuerza mayor aquellos donde el producto deja de tener sentido en el contexto actual. No se considera un caso de fuerza mayor el hecho que un cliente no tenga dinero de respaldo ya que la mayoria de empresas de desarrollo cobran por adelantado.

En caso de cancelación las ceremonias se mantienen, haciendo tanto el review como el retrospective.

Sprint Planing (Sprint Meeting)

Una vez el Product Owner haya definido el objetivo mínimo realizable y tenga las historias de usuario, se reúne el equipo para planificar el sprint. Esta ceremonia tiene una duración máxima de 8 horas y su objetivo es la planificación y distribución del periodo de tiempo en el que se desarrollará la Feature (característica) cualquier otra característica será contemplada en otro Planing. Asegurarse de eso es trabajo del Scrum Master. Las dos preguntas que guían esta ceremonia son:

que podemos desarrollar?

en esta pregunta el Product Owner pone a discusión la característica o funcionalidad a desarrollar en el sprint. La característica viene acompañada de sus respectivas historias de usuario (requerimientos del cliente) y del Backlog (requeriminetos totales) para dar una perspectiva global. y aquí se divide en dos posibilidades

primero, si es el primer sprint del desarrollo o el equipo es nuevo, o alguno de sus miembros es nuevo, se discute los proyectos anteriores (sprints) en caso de haberlos, se estima la capacidad de trabajo (stars) y se evalua la feature presente.

segundo, si es un sprint adicional, con el mismo equipo de desarrollo, en el mismo proyecto; se evaluá el último sprint en cuanto a características técnicas y tecnologías, la velocidad del equipo (medida en características - en git se usan los issues- o lineas de codigo - en github pull request-) y la gestión de dificultad del equipo (medidas en puntos(stars)).

una vez esta establecido el Sprint Goal (objetivo) se crea un nuevo scrum board (en github se hace desde projects) y se establece como meta a lograr.

como puedo desarrollarlo?

cuando el Sprint Goal esta listo y nuestro tablero creado, se empieza a enumerar las tareas y tecnologías que se usaran para poder lograr ese objetivo. Esta dinámica es más como una lluvia de idea basada en la experiencia técnica. En caso de haber dos tecnologías o caminos que resuelvan lo mismo es el equipo quien debe decidir como resolver el conflicto. usualmente después de escuchar las ventajas y desventajas técnicas de cada tecnología.

con la lista de actividades calculamos el tiempo o dificultad (medida en estrellas o puntos) y debería arrojarnos como tiempo base menos de un día de trabajo. si es más que eso se puede continuar subdiviendo en tareas más simples hasta lograr periodos menores a un día o periodo de trabajo.

A partir de allí el equipo se auto-organiza para empezar a completar cada tarea según sus habilidades o intereses,esto parte de mantener el equipo altamente motivado. Estas tareas quedan consignadas en un sistema llamado un Sprint Backlog, que serán los "requerimientos" de ese Sprint.

En este punto el trabajo del Product Owner es aclarar cada pregunta del equipo, si no es posible eso comprometerse en un tiempo razonable a conseguir y gestionar la información y recursos. En caso de evidenciar un exceso de trabajo deberán renegociar con el Product Owner, del mismo modo que al tener poco.

Al finalizar la reunión debe ser claro para todos que tareas, que tecnologías y que tiempos van a usar para el desarrollo del Goal. Resumiendo el Planing es el mapa para encontrar el tesoro.

scrum Daily

es una reunión diaria del scrum team con un máximo de 15 minutos que tiene como objetivo sincronizar las actividades del equipo para un periodo máximo de 24 horas o un periodo de trabajo. para hacer esta sincronización se revisa el avance desde el último scrum daily y se proyecta hasta el siguiente. cada miembro del equipo debe responder:

el Product Owner y el Scrum Master deben estar atentos a esta última duda para poder gestionar los recursos y ayudar a lograr ese Goal (objetivo) en el tiempo del sprint. Sin embargo el Equipo de desarrollo es el responsable de la reunión, que quiere decir que debe llevarse a cabo con o sin Scrum Master y Product Owner.

Sprint Review

al finalizar el Sprint se ejecuta una nueva ceremonia con todo el Scrum Team para revisar el incremento del Goal de ese Sprint. Es una reunión con un máximo de 4 horas y se evalua:

Resumiendo en esta ceremonia nos enfocamos en evaluar el objetivo y sus caracteristicas técnicas. el desarrollo conceptual y factico del producto y las oprtunidades de negocio, de tecnologías y de variación que existen para el PRODUCTO. No es una reunión de funcionamiento del equipo, de las personas o de las relaciones interpersonales.

Sprint Retrospective

es una reunión del Scrum Team de maximo 3 horas que se realiza como finalización del Sprint. se enfoca en evaluar las relaciones interpersonales, el trabajo en equipo, las metricas de manejo de dificultad y tiempos, las herramientas usadas para la gestión. no evalua una persona sino el conjunto de ellas para esto se usa como insumo la evidencia del restrospective anterior que determinaria que habia que mejorar y se evalua si se cumplio o que hizo falta para lograrlo; se deja evidencia de lo que se esta haciendo bien y se crea el plan de mejora para la siguiente meta de trabajo en equipo.

En resumen esta reunión se enfoca en las habilidades blandas del trabajo en equipo para mejorar como grupo, NUNCA SE EVALUA UNA PERSONA SOLA. Al terminarlo se da por finalizado el Sprint.

Artifacts

son herramientas de Scrum que nos permiten revisar los cambios y adaptarnos a ellos de modo veloz.

Backlog (Product Backlog)

es una lista ordenada realizada por el Producto Owner, con los stakeholders, los clientes, los usuarios, etc. donde están los requerimientos para el desarrollo de una aplicación, tecnología o proyecto.

la lista al igual que todo el resto de las dinamicas de Scrum puede cambiar y sus primeras versiones solo muestran las necesidades iniciales e inmediatas sobre un producto, tecnologia o aplicación. A diferencia de las metodologias en cascada o tradicionales diferentes requerimientos no son necesariamente diferentes productos, sino que son incrementos del mismo producto. Por ejemplo: el navegador google Chrome se libera cada 6 semanas, y su lista de requerimientos (RoadMap) es variable cada 6 meses dependiendo de la visión tecnologica de alphabet, lla casa matriz de google.

esto ocurre porque en la medida que los usuarios de un producto se "adueñan" de el piden o implementan caracteristicas diferentes que al principio se conocen como add-ons (Añadidos o extensiones, de ahí que sena tan populares en casi todas las nuevas aplicaciones) y que posteriormente se implementan como parte del nucleo para satisfacer los usuarios. Esto no significa que sea otro producto sino que el CAMBIO del mercado obligo a incrementar el valor del mismo desde la programación de la aplicación.

este Artefacto es responsabilidad y de manejor exclusivo de Product Owner.

Sprint Backlog

de la lista general de requeriminetos (Backlog) se seleccionan algunas tareas para cada sprint (puede ser solo una); despues de esa selección y con una ceremonia de planing se crea un plan para lograr esas acciones, y posteriormente se crean unas actividades que permiten evidenciar commo se ejecutará cada cosa. a este recurso le llamamos Sprint Backlog.

Este artifact debe ser lo suficientemente granular para que en cada Scrum daily podamos saber como vamos avanzando hacia el objetivo. Este artefacto es propiedad y uso exclusivo del DevTeam aunque puede recibor *sugerencias" del resto del Scrum Team.

el Sprint Backlog es generalmente registrado en un Scrum board (en el caso de Git en projects) y permite ver la movilidad y cambio al pasar una tarea de planeada a ejecutada.

TODO